I. Technical Field
This technology pertains to wireless communications, and particularly to compression of packet headers transmitted in a radio access network.
II. Related Art and Other Considerations
Due to the tremendous success of the Internet, it has become a challenging task to make use of the Internet Protocol (IP) over all kinds of links. However, because of the fact that the headers of the IP protocols are rather large, it is not always a simple task to make this come true for narrow band links, for example wireless cellular links. As an example, consider ordinary speech data transported by the protocols (IP, UDP, RTP) used for Voice-over-IP (VoIP), where the header may represent about 70% of the packet—resulting in a very inefficient usage of the link.
The term header compression (HC) comprises the art of minimizing the necessary bandwidth for information carried in headers on a per-hop basis over point-to-point links. The techniques in general have a more than ten-year-old history within the Internet community; several commonly used protocols exist such as RFC 1144 (VJ) Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, IETF RFC 1144, IETF Network Working Group, February 1990; RFC 2507 (IPHC) Mikael Degermark, Björn Nordgren, Stephen Pink. IP Header Compression. IETF RFC 2507, IETF Network Working Group, February 1999; and RFC 2508 (CRTP) Steven Casner, Van Jacobson. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, IETF RFC 2508, IETF Network Working Group, February 1999.
Header compression takes advantage of the fact that some fields in the headers are not changing within a flow, or change with small and/or predictable values. Header compression schemes make use of these characteristics and send static information only initially, while changing fields are sent with their absolute values or as differences from packet to packet. Completely random information has to be sent without any compression at all.
Header compression is thus an important component to make IP services over wireless, such as voice and video services, economically feasible. Header compression solutions have been developed by the Robust Header Compression (ROHC) Working Group of the IETF to improve the efficiency of such services.
Other optimizations, such as other types of compression, can also be used to further increase the performance of bandwidth-limited systems. These include payload compression [see, e.g., Pereira, R., IP Payload Compression Using DEFLATE, IETF RFC 2394, December 1998; and Friend, R. et R. Monsour, IP Payload Compression Using LZS, IETF RFC 2395, December 1998]; signaling compression [see, e.g., Baugher M. et al., The Secure Real-time Transport Protocol (SRTP), IETF RFC 3711, March 2004]; header removal and regeneration, and header compression [see, e.g., RFC 1144 (VJ) Van Jacobson, Compressing TCP/IP Headers for Low-Speed Serial Links, IETF RFC 1144, IETF Network Working Group, February 1990; RFC 2507 (IPHC) Mikael Degermark, Björn Nordgren, Stephen Pink. IP Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999; RFC 2508 (CRTP) Steven Casner, Van Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, IETF RFC 2508, IETF Network Working Group, February 1999; Koren, T., Casner, S., Geevarghese, J., Thompson B. and P. Ruddy, Enhanced Compressed RTP (CRTP) for Links with High Delay, Packet Loss and Reordering. IETF RFC 3545, IETF Network Working Group, July 2003; Carsten Bormann, et al. RObust Header Compression (ROHC). Framework and four profiles. RTP, UDP, ESP and uncompressed. IETF RFC 3095, April 2001); Jonsson, L. and G. Pelletier, RObust Header Compression (ROHC). A compression profile for IP, IETF RFC 3843, June 2004; Pelletier, G., RObust Header Compression (ROHC). Profiles for UDP-Lite, IETF RFC 4019, April 2005; Pelletier, G., Sandlund, K. and L. Jonsson, Robust Header Compression (ROHC). A Profile or TCP/IP, Internet Draft (work in progress), <RFC4996, July 2007 http://tools.ietf.org/rfc/rfc4996.txt>, June 2006; and Pelletier, G. et Sandlund, K., Robust Header Compression Version 2 (ROHCv2). Profiles for RTP, UDP, IP, ESP and UDP-Lite, Internet Draft (work in progress), draft-pelletier-rohc-rohcv2-profiles-01.txt, May 2007 http://tools.ietf.org/id/draft-ietf-rohc-rfc3095bis-rohcv2-profiles-01.txt, June 2006. All the foregoing are incorporated herein by reference in their entirety. Any of these types of compression may be designed to make use of sequence numbers and checksums.
Traditionally, the UTRAN architecture has separated functionalities into different nodes as follows: the Radio Network Control (RNC) function handles sequencing when lossless relocation is supported (optional). The ciphering (e.g., encryption) occurs in the NodeB (i.e. radio base station transmitter), and requires in-order delivery of each Service Data Units (SDUs) to maintain the ciphering context. In order to ensure that the ciphering does not loose synchronization, a Layer 2 (L2) Frame Checksum Sequence (FCS) is normally used, adding additional octets for transmission over the air interface. The decision about what quality of service would be applied to a packet is mainly performed in the RNC, while it is enforced at the transmission point, the NodeB.
The state-of-the-art in terms of QoS in wireless systems is to first establish a Radio Bearer (RB) (or “connection”) for a specific service, for one or more combinations of e.g. IP source and destination addresses, UDP source and destination ports. The RB includes a set of parameters or traffic handling requirement that the transmitter should fulfill. This same processing is applied for any packet belonging to that service and being routed to the same RB, independently of other possible QoS differentiation. Packets belonging to the same service may be “routed” to different radio bearers by some selector process, but this is done independently from the transmitter state (queue managements, scheduling, CIR, cell load and other possible factors that could influence the treatment of a packet) and not in the transmitting node, as the RB edges are not located in the transmitting node per definition.
The above limits the NodeB in its capability to adjust its transmission mechanisms, e.g. Hybrid Automatic Retransmission reQuest (H-ARQ), scheduling and queue management, to a finer granularity for each packet and also between multiple receivers being served within a cell. The NodeB is often limited to its static knowledge of the radio bearer (i.e. the connection) and of the QoS parameters associated to it and to which the SDU belongs to, and possibly from some other information propagated over the (standardized) interface between the RNC and the NodeB associated to the packet. Some NodeBs may inspect the SDU before transmission to try to extract further information, however little is available as SDUs at this point have already been processed by e.g. header compression and/or encryption functions.
In contrast, the current proposal for the SAE/LTE architecture is to remove the RNC, which leads to that the ciphering function and the PDCP function, which hosts the header compression function, are now located in the same node (access gateway—aGW). Both the ciphering and the PDCP functions terminate into the User Equipment (UE) on the other end. In other words, the interface between the aGW node and the eNB node is deemed to be untrusted. The S1 interface thus requires that ciphering be applied to the user traffic, and this propagates up to the user equipment unit (UE). A secure tunnel over the S1 interface would not solve the problem of trust of the eNB node. Finally, the mapping of the QoS to radio bearer (i.e. connection) remains, as the limitations attached to it.
Often QoS is defined in a connection-oriented fashion (per flow/receiver or per physical channel), or because the traditional distribution of functions (e.g. encryption and header compression) prevents this combination. Such traditional definition/usage of QoS is illustrated by FIG. 16. In FIG. 16, the L2 ciphering traditionally occurs in a different node than that where the enforcement of the QoS occurs, i.e., the entire compressed header is encrypted.
Header compression “hides” the QoS information carried in upper layers, while it adds its own “sensibility” to how individual header compressed packets are QoS handled. The same applies with security. As shown in FIG. 17, the state-of-the-art often uses an interface between the L2 and upper layers, and when multiple L2 are traversed, each L2 has to interface with each other to translate the QoS requirement of each packet.
One problem is how to derive and how to propagate the QoS information that is the most suitable for a Protocol Data Unit (PDU), and how this information can be propagated to the transmitter so that more flexible algorithms to enforce QoS requirements may be implemented. Traditionally, this has not been possible to do within the header compression channel, as functions where often separated into different physical nodes and “interfering” with each other.